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Preface 


This technical manual was developed under the Office of Safety and Mission Assurance continuous 
training initiative. The structured information contained in this manual will enable the reader to efficiently and 
effectively identify and control the technical detail needed to ensure that flight system elements mate properly 
during assembly operations (both on the ground and in space). 

Techniques used throughout the Federal Government to define and control technical interfaces for both 
hardware and software were investigated. The proportion of technical information actually needed to 
effectively define and control the essential dimensions and tolerances of system interfaces rarely exceeded 50 
percent of any interface control document. Also, the current Government process for interface control is very 
paper intensive. Streamlining this process can improve communication, provide significant cost savings, and 
improve overall mission safety and assurance. 

The primary thrust of this manual is to ensure that the format, information, and control of interfaces 
between equipment are clear and understandable, containing only the information needed to guarantee 
interface compatibility. The emphasis is on controlling the engineering design of the interface and not on the 
functional performance requirements of the system or the internal workings of the interfacing equipment. 
Interface control should take place, with rare exception, at the interfacing elements and no further. 

There are two essential sections of the manual. The first, Principles of Interface Control, discusses how 
interfaces are defined. It describes the types of interface to be considered and recommends a format for the 
documentation necessary for adequate interface control. The second, The Process: Through the Design Phases, 
provides tailored guidance for interface definition and control. 

This manual can be used to improve planned or existing interface control processes during system design 
and development. It can also be used to refresh and update the corporate knowledge base. The information 
presented herein will reduce the amount of paper and data required in interface definition and control processes 
by as much as 50 percent and will shorten the time required to prepare an interface control document. It also 
highlights the essential technical parameters that ensure that flight subsystems will indeed fit together and 
function as intended after assembly and checkout. 
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Chapter 1 

Introduction 


This technical manual resulted from an investigation of 
techniques used throughout NASA and other Federal Govern- 
ment agencies to define and control technical interfaces for 
both hardware and software. The processes described herein 
distill the requirements for interface definition and control into 
a concise set of parameters that control the design of only the 
interface-related elements rather than providing extraneous 
design detail that must subsequently be configuration 
managed. 

The purpose of this manual is to provide guidelines for 
establishing and conducting the interface control process so 
that items produced by different design agencies satisfactorily 
mate and operate in a way that meets mission requirements. 
These guidelines were drawn from the methodologies of a 
number of highly successful programs and therefore represent 
a compilation of “lessons learned.” 

The principles and processes of interface definition and 
control presented in this document apply to all projects and 
programs but may be tailored for program complexity. For 
example, the interface control process may be less formal for a 
project or program that requires only one or two end items and 
has few participants; however, the formal interface control 
document is still necessary. For a project or program that 
requires a number of end items and where several participants 
are involved, a carefully followed interface control process is 
imperative, with comments, decisions, agreements, and com- 
mitments fully documented and tracked. Individual managers 
should provide the implementation criteria for their interface 
control processes early in the project or program (ref. 1). 

This manual covers the basic principles of interface defini- 
tion and control: how to begin an interface control program 
during the development of a new project or program, how to 
develop and produce interface documentation, how to manage 
the interface control process, and how to transfer interface 
control requirements to hardware and software design. 

Interface definition and control is an integral part of system 
engineering. It should enter the system engineering cycle at the 
end of the concept development phase. Depending on whether 
the system under development is designed for one-time or 
continuous use, the process may continue for the full life cycle 
of the system. Interface definition and control should not be 
equated to configuration management or configuration control. 
Rather it is a technical management tool that ensures that all 
equipment will mate properly the first time and will continue to 
operate together as changes are made during the life cycle of the 
system. Figure 1 . 1 depicts the elements of the system engineer- 
ing cycle and is used in chapter 3 to describe the application of 
the interface discipline at different parts of the life cycle (ref. 2). 


Establishing a system that ensures that all interface param- 
eters are identified and controlled from the initial design 
activities of a program is essential. It is not necessary that the 
fine details of these parameters be known at that time, but it is 
very important that the parameters themselves are identified, 
that everything known about them at that time is recorded and 
controlled, and that voids 1 are identified and scheduled for 
elimination. The latter requirement is of primary importance to 
the proper design of any interface. Initial bounding of a void and 
scheduled tightening of those bounds until the precise dimen- 
sions or conditions are identified act as a catalyst to efficient 
design and development. An enforced schedule for eliminating 
voids is one of the strongest controls on schedule that can be 
applied (ref. 3). 

The process of identifying, categorizing, defining, and docu- 
menting interfaces is discussed in the following chapter. Guid- 
ance for the analysis of interface compatibility is also provided. 



Figure 1.1 — System engineerig cycle. (The 
requirements definition phase must include 
the requirements for the interfaces as well as 
those which will eventually be reflected in the 
interface control document.) 


1 A “void” is a specific lack of information needed for control of an interface 
feature. Control and elimination of voids is fundamental to a strong interface 
definition and control program. 
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1.1 Training 2 


1. The processes explained in this manual for interface 

definition and control are 

A. A concise set of parameters that control the design of the 
interface-related elements 

B. A set of design details needed for configuration manage- 
ment 

2. The process is very important for projects that require 

A. A number of end items 

B. Involvement of several participants 

C. Comments, decisions, agreements, and commitments 
that must be fully documented and tracked 

D. All of the above 

3. What elements does the system engineering cycle contain? 

A. Mission needs, requirements, and integration 

B. Technical oversight, core design, and system configura- 
tion 


C. Mission needs definition, risk and systems analysis, 
concept and requirements definitions, system integra- 
tion, configuration management, technical oversight, 
and verification and validation 

4a. What is a void? 

A. Bracketed data 

B. Wrong data 

C. Lack of information needed 

4b. How should voids be handled? 

A. Voids should be identified and their elimination 
scheduled. 

B. Data should be analyzed. 

C Supplier should be guided. 

4c. Name a strong control needed for voids. 

A. Precise dimensions 

B. Enforced schedule 

C. Identified catalysts 


^Answers are given at the end of this manual. 
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Chapter 2 

Principles of Interface Control 


2.1 Purpose of Interface Control 

An interface is that design feature of a piece of equipment 3 
that affects the design feature of another piece of equipment. 
The purpose of interface control is to define interface require- 
ments so as to ensure compatibility between interrelated pieces 
of equipment and to provide an authoritative means of control- 
ling the design of interfaces. Interface design is controlled by an 
interface control document (ICD). 

These documents 

1 . Control the interface design of the equipment to prevent 
any changes to characteristics that would affect compat- 
ibility with other equipment 

2. Define and illustrate physical and functional characteris- 
tics of a piece of equipment in sufficient detail to ensure 
compatibility of the interface, so that this compatibility 
can be determined from the information in the ICD alone 

3. Identify missing interface data and control the submis- 
sion of these data 

4. Communicate coordinated design decisions and design 
changes to program participants 

5. Identify the source of the interface component 

ICD’s by nature are requirements documents: they define 
design requirements and allow integration. They can cause 
designs to be the way they are. They record the agreed-to design 
solution to interface requirements and provide a control mecha- 
nism to ensure that the agreed-to designs are not changed by one 
participant without negotiated agreement of the other participant. 

To be effective, ICD’s should track a schedule path compat- 
ible with design maturation of a project (i.e., initial ICD’s 
should be at the 80% level of detail at preliminary design 
review, should mature as the design matures, and should reach 
the 99% mark near the critical design review). 

2.2 Identifying Interfaces 

Identifying where interfaces are going to occur is a part of 
systems engineering that translates a mission need into a 
configured system (a grouping of functional areas) to meet that 
need. Each functional area grouping is assigned certain perfor- 


"5 

For purposes of this manual, a piece of equipment is a functional area assigned 
to a specific source. Thus, a piece of equipment can be an element of the space 
station, a system of a spacecraft, a work package assigned to a contractor, or a 
subsystem. 


mance requirements. These performance requirements are trans- 
lated into design requirements as the result of parametric 
studies, tradeoff studies, and design analyses. The design 
requirements are the basis for developing the system specifica- 
tions. The boundaries between the functional areas as defined 
in the system specifications become the interfaces. Early inter- 
face discussions often contribute to final subsystem specifica- 
tions. Interface characteristics, however, can extend beyond the 
interface boundary, or interface plane, where the functional 
areas actually come together. The interface could be affected 
by, and therefore needs to be compatible with, areas that 
contribute to its function but may not physically attach. For 
example, it may be necessary to define the path of a piece of 
equipment as it traverses through another piece of equipment 
and rotates and articulates to carry out its function. Electrical 
characteristics of a transmitter and receiver separated by an 
interface plane may have to be defined for each to properly 
function. Similarly, the acoustic energy produced by one com- 
ponent and transmitted through the structure or onto another 
component may need a corresponding definition. 

Identifying interfaces early in a program is essential to 
successful and timely development. Functional analyses are 
used for analyzing performance requirements and decompos- 
ing them into discrete tasks or activities (i.e., decomposing the 
primary system functions into subfunctions at ever increasing 
levels of detail). Functional block diagrams are used to define 
data flow throughout the system and interfaces within the 
system. Once the segments and elements within a system have 
been defined, a top-level functional block diagram is prepared. 
The block diagrams are then used in conjunction with N- 
squared diagrams to develop interface data flows. The N- 
squared diagram is a technique used extensively to develop data 
interfaces but can also be refined for use in defining hardware 
interfaces. However, use of this tool in this manual will be 
restricted to interface categorization. Additional description is 
provided in section 3.1.1. 

In summary, identifying where interfaces are going to occur 
begins the systems integration component of systems engineer- 
ing and must start early in design planning. The interface 
boundaries or planes vary from program to program depending 
on how design and development responsibilities are assigned. 
Interface control can occur within a functional area of other 
design and development agents. Therefore, interfaces can be 
identified at many levels, for example, 

1 . Center to center 

2. Discipline to discipline (e.g., propulsion to guidance, 
sensor to structure, or power to users) 

3. Contractor to contractor 
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4. Center to contractor to discipline 

5. Program to program (e.g., shuttle to National Launch 
System) 

Once interface boundaries or planes are established, the 
interfaces must be categorized and defined. 

2.3 Categorizing (Partitioning) and 
Defining Interfaces 

Categorizing, or partitioning, interfaces separates the inter- 
face features by technical discipline and allows each category, 
in most cases, to proceed through the definition process 
independently. 

The following basic interface categories (defined by the 
types of feature and data they encompass) are recommended for 
use in most programs: 

1. Electrical/functional 

2. Mechanical/physical 

3. Software 

4. Supplied services 

During the early phases of systems engineering, interfaces 
may be assigned only the high-level designation of these 
categories. As the system becomes better defined, the details of 
the physical and functional interface characteristics become 
better defined and are documented. 

An interface can be assigned to one of these categories by a 
number of processes of elimination. The one recommended for 
use is the A-squared diagram (ref. 4), which is currently being 
used by some NASA centers. 

23.1 Electrical/Functional 

Electrical/functional interfaces are used to define and con- 
trol the interdependence of two or more pieces of equipment 
when the interdependence arises from the transmission of an 
electrical signal from one piece of equipment to another. All 
electrical and functional characteristics, parameters, and toler- 
ances of one equipment design that affect another design are 
controlled by the electrical/functional ICD. The functional 
mechanizations of the source and receiver of the interface 
electrical signal are defined, as well as the transmission 
medium. 

The interface definition includes the data and/or control 
functions and the way in which these functions are represented 
by electrical signals. Specific types of data to be defined are 
listed here: 

1 . Function name and symbol 

2. Impedance characteristics 


3. Shielding and grounding 

4. Signal characteristics 

5. Cable characteristics 

6. Data definition 

7. Data transmission format, coding, timing, and updating 

8. Transfer characteristics 

9. Circuit logic characteristics 

10. Electromagnetic interference requirements 

1 1 . Data transmission losses 

12. Circuit protective devices 

Other data types may be needed. For example, an analog 
signal interface document would contain function name and 
symbol, cable characteristics, transfer characteristics, circuit 
protective devices, shielding, and grounding; whereas a digital 
data interface would contain function name and symbol, data 
format, coding, timing and updating, and data definition. 

Additional datatypes under the electrical/functional heading 
are 

1 . Transmission and receipt of an electrical/electromag- 
netic signal 

2. Use of an electrically conductive or electromagnetic 
medium 

Appendix A shows recommended formats for electrical and 
functional interface control drawings. 

23.2 Mechanical/Physical 

Mechanical/physical interfaces are used to define and con- 
trol the mechanical features, characteristics, dimensions, and 
tolerances of one equipment design that affect the design of 
another subsystem. They also define force transmission re- 
quirements where a static or dynamic force exists. The features 
of the equipment that influence or control force transmission 
are also defined in this ICD. Mechanical interfaces include 
those material properties of the equipment that can affect the 
functioning of mating equipment, such as thermal and galvanic 
characteristics. Specific types of data defined are 

1. Optical characteristics 

2. Parallelism and straightness 

3. Orientation requirements 

4. Space or provisions required to obtain access for perform- 
ing maintenance and removing or replacing items, in- 
cluding space for the person performing the function 

5. Size, shape, mass, mass distribution, and center of gravity 

6. Service ports 

7. Indexing provisions 

8. Concentricity 

9. Surface finish 

1 0. Hard points for handling 
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11. Sealing, pressurization, attachment, and locking 
provisions 

12. Location and alignment requirements with respect to 
other equipment 

13. Thermal conductivity and expansion characteristics 

14. Mechanical characteristics (spring rate, elastic proper- 
ties, creep, set, etc.) 

15. Load-carrying capability 

16. Galvanic and corrosive properties of interfacing 
materials 

Other data types may be needed. For example, an ICD 
controlling a form-and-fit interface would generally contain 
such characteristics as size and shape of the item, location of 
attachment features, location of indexing provisions, and weight 
and center of gravity of the item. However, an ICD controlling 
a structural load interface would contain weight and center of 
gravity, load-carrying capability, and elastic properties of the 
material if applicable to the loading conditions. Not all ICD’s 
controlling a form-and-fit interface would have to contain all 
types of data given in this example, but some form-and-fit 
interface definitions contain more than the 16 types of data 
listed. Indexing definitions may require angularity, waviness, 
and contour definitions and tolerances. 

Additional data types under the mechanical/physical head- 
ing would be 

1 . Dimensional relationships between mating equipment 

2. Force transmission across an interface 

3. Use of mechanically conductive media 

4. Placing, retaining, positioning, or physically transporting 
a component by another component 

5. Shock mitigation to protect another component 

Appendix B (from ref. 5) shows a mechanical/physical draw- 
ing. 

This extensive variety of possibilities and combinations 
prevents assigning a standard set of data types or level of detail 
to a form-and-fit interface. Each interface must be analyzed and 
the necessary controlling data identified before the proper level 
of interface definition and control can be achieved. This holds 
true for all examples given in this chapter. 

23.3 Software 

A software interface defines the actions required when 
interfacing components that result from an interchange of 
information. A software interface may exist where there is no 
direct electrical interface or mechanical interface between two 
elements. For example, whereas an electrical ICD might define 
the characteristics of a digital data bus and the protocols used 
to transmit data, a software interface would define the actions 
taken to process the data and return the results of the process. 
Software interfaces include operational sequences that involve 


multiple components, such as data-processing interactions 
between components, timing, priority interrupts, and watchdog 
timers. Controversy generally arises in determining whether 
these relationships are best documented in an electrical/func- 
tional ICD, a software ICD, or a performance requirements 
document. Generally, software interface definitions include 

1 . Interface communication protocol 

2. Digital signal characteristics 

3. Data transmission format, coding, timing, and updating 

requirements 

4. Data and data element definition 

5. Message structure and flow 

6. Operational sequence of events 

7. Error detection and recovery procedures 

Other data types may be needed. Appendix C provides an 
example of a software interface signal. 

23.4 Supplied Services 

Supplied services are those support requirements that a piece 
of equipment needs to function. Supplied services are provided 
by an external separate source. This category of interface can be 
subdivided further into electrical power, communication, fluid, 
and environmental requirements. The types of data defined for 
these subcategories are 

1. Electrical power interface: 

a. Phase 

b. Frequency 

c. Voltage 

d. Continuity 

e. Interrupt time 

f. Load current 

g. Demand factors for significant variations during 
operations 

h. Power factor 

i. Regulation 

j. Ripple 

h. Harmonics 

l. Spikes or transients 

m. Ground isolation 

n. Switching, standby, and casualty provisions 

2. Communication interface: 

a. Types of communication required between equip- 
ment 

b. Number of communication stations per communica- 
tion circuit 

c. Location of communication stations 

3. Fluid interface: 

a. Type of fluid required 

i. Gaseous 

ii. Liquid 
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b. Fluid properties 

i. Pressure 

ii. Temperature 

iii. Flow rate 

iv. Purity 

v. Duty cycle 

vi. Thermal control required (e.g., fluid heat lost or 
gained) 

4. Environmental characteristic interface: 

a. Ambient temperature 

b. Atmospheric pressure 

c. Humidity 

d. Gaseous composition required 

e. Allowable foreign particle contents 

Other data types may be needed. Appendix D shows an ex- 
ample of a supplied services interface for air-conditioning and 
cooling water. 

2.4 Documenting Interfaces 

Once an interface has been categorized and its initial con- 
tents defined, that interface definition must be recorded in a 
document that is technically approved by the parties (designer 
and manager) and the owners of both sides of the interface. The 
document then is approved by the next higher level in the 
project management structure and becomes the official control 
for interface design. 

The program manager must ensure that compliance with the 
approved interface control document is mandatory. Each level 
of program management must ensure that the appropriate 
contractors and Government agencies comply with the docu- 
mentation. Therefore, technical approval of the interface con- 
trol document indicates that the designated approving 
organization is ready to invoke the interface control document 
contractually on the approving organization’s contractor or 
supporting organization. 

The interface categories can be grouped together in one 
document, or each category can be presented in a separate 
document (i.e., electrical ICD’s, mechanical ICD’s, etc). The 
format for interface control documents is flexible. In most cases 
a drawing format is the easiest to understand and is adaptable 
to the full range of interface data. 

The specification format (ref. 6) can also be used. The use of 
this type of format enables simple changes through the removal 
and insertion of pages; however, the format is often difficult to 
use when presenting complex interface definitions that require 
drawings, and normally requires many more pages to convey 
the same level of information. 

In either case there must be agreement on a standard for data 
presentation and interpretation. ANSI standard Y14.5 (ref. 7) 
can be used for dimensions, along with DOD-STD-lOO 


(ref. 8), for general guidance of a drawing format. The specifi- 
cation format should use MIL-STD-490 (ref. 6) for paragraph 
numbering and general content. 

Some large programs require large, detailed ICD’s. Main- 
taining a large, overly detailed document among multiple 
parties may be more difficult than maintaining a number of 
smaller, more focused documents. Grouping small documents 
by major category of interface and common participants is one 
of the most effective and efficient strategies. It minimizes the 
number of parties involved and focuses the technical disci- 
plines, greatly streamlining the decision process and permitting 
much shorter preparation time. However, interfaces can be 
multidisciplinary and separate documents can result in mis- 
communications. 

2.5 Identifying Steady-State and 
Non-Steady-State Interfaces 

Interfaces can vary from a single set that remains constant for 
the life of a program to a multiple set of documents that 
reconfigures during specific events in the life of a system. The 
first category would be used for an interplanetary probe. The 
interfaces of its instruments with the basic spacecraft structure 
would remain the same from assembly for launch throughout 
the life of the experiment. However, a continually evolving 
platform, such as a lunar base, would perhaps be controlled in 
a series of interface documents based on the assembly sequence 
of the base. An initial base would be established and later made 
more complex with additional structures and equipment deliv- 
ered by subsequent lunar flights. Pressurized elements, logistic 
elements, power-generating sources, habitats, laboratories, and 
mining and manufacturing facilities might be added and 
reconfigured over time. Each configuration would require a set 
of interface control documents to ensure compatibility at the 
construction site as well as with the transportation medium 
from Earth to Moon. Interfaces that remained constant during 
this process might be termed steady state and require no further 
consideration once the interface was verified and delivered; 
whereas interfaces that would evolve from the initial 
configuration through multiple iterations would require multi- 
coordination of interface parameters and schedules. The selec- 
tion of interface categories should identify the steady-state or 
non-steady-state nature of interfaces as well as their initial 
designations (ref. 9). 

2.6 Selecting a Custodian 

Selecting an ICD custodian can depend on several factors 
(e.g., percentage of interface ownership, relative mission im- 
portance of interface sides, and relative investment of interface 
sides). However, it is generally most effective if the custodian 
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selected has an objective point of view. An example of this 
would be someone who is independent of either side of the 
interface (i.e., without any “vested interest” in the interface 
hardware or software). Objectivity permits unbiased control of 
the interface, involvement of the custodian as an objective 
mediator, and documentation of the interface on a noninterfer- 
ence basis with program/project internal design. Selecting an 
independent interface custodian should be the first step in 
establishing an interface control organization. A set of criteria 
should be used to select the custodian by weighting the content 
and interests of the interface with the needs of interface control . 
One set of criteria is as follows: 

1 . Integration center: Is one center accountable for integrat- 
ing the interfaces controlled by this ICD? This criterion is 
considered the most important because the integration center 
will have the final responsibility for certifying flight readiness 
of the interfaces controlled in the ICD. 

2. U.S. center: Is the participant a U.S. center? This crite- 
rion is considered the next most important because of agency 
experience and projected responsibility. 

3. Flight hardware or software: Is the interfacing article 
flight hardware or software (as opposed to support hardware or 
software)? Flight hardware or software takes precedence. 

4. Flight sequence: Does one side of the interfacing equip- 
ment fly on an earlier manifest than the other? An earlier flight 
sequence takes precedence over follow-on interfacing 
hardware. 

5. Host or user: Is the interfacing article a facility (as 
opposed to the user of the facility)? Procedure in this criterion 
is guided by the relative priority of the interfacing articles. 

6. Complexity: How complex is the interfacing equipment 
(relative to each side)? The more complex side of the interface 
normally takes precedence. 

7. Behavior: How active is the interfacing equipment? The 
active side normally takes precedence over the passive side. 

8. Partitions: How are the partitions (categories) used by the 
interfacing equipment? The relative importance of the parti- 
tions to the interface is acknowledged, and selection of the 
custodian is sensitive to the most important partition 
developers. 

Scores are assigned to each piece of interfacing equipment 
for each criterion. These scores can be determined by many 
different methods. Discrete values can be assigned to the first 
four criteria. A score of 1 .0 is assigned if the interfacing piece 
of equipment is unique in meeting the criterion, the other piece 
of equipment then receives a score of 0.0. Scores of 0.5 are 
assigned to both sides if both (or neither) of them meet the 
criterion. There is no definitive way of assigning scores to the 
last four criteria; however, verbal consensus or an unbiased 
survey can be used to assign scores. Also, the partition criteria 
can be scored by partition evaluation analysis (ref. 4). 


2.7 Analyzing for Interface 
Compatibility 

The interface definitions to be documented on the ICD’s 
must be analyzed for compatibility before the ICD is authenti- 
cated. Appendix E provides guidance on how compatibility 
analyses may be performed. They vary in their complexity from 
a simple inspection of the interface definitions to complex 
mathematical analyses where many variables are involved. 

Regardless of complexity, the compatibility analysis should 
be documented and maintained as backup information for the 
ICD. It can be used to expedite any changes to the interface 
definition by providing a ready means for evaluating the 
compatibility of the proposed change. The compatibility analy- 
sis also can be used to document how the interface definition 
was arrived at and why the definition is presented as it is on 
an ICD. 

2.8 Verifying Design Compliance With 
Interface Control Requirement 

The ICD can only fulfill its purpose if the contractors’ 
detailed design drawings and construction practices adhere to 
the Limits imposed by the ICD. Verifying compliance of the 
design as well as of the construction process is an integral part 
of interface control. 

Each contractor should be assigned the responsibility of 
denoting on their manufacturing and inspection drawings or 
documents those features and characteristics that, if altered, 
would affect interfaces controlled by the ICD’s. To ensure that 
all ICD requirements are covered, the contractor should select, 
at the highest assembly level at which the equipment is in- 
spected, the features and characteristics to be denoted. Any 
design change affecting an ICD-controlled feature or charac- 
teristic would be clearly identified even at the assembly level 
(ref. 10). 

Entries identified as “to be resolved” (TBR) can be bracketed 
or shaded to indicate preliminary interface information or an 
interface problem. This information is subject to further review 
and discussion and is an interim value for use in evaluating 
effects. Entries identified as “to be supplied” (TBS) represent 
data or requirements to be furnished. Appendix F shows a 
typical bracket system. 


2.9 Verifying Contract-Deliverable Item 

Each contract-deliverable item that is a mating side to an ICD 
interface should also be tested or measured to verify that the 
item complies with the requirement as specified in the ICD. The 
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responsibility for administering and reporting on this verifica- 
tion program could be assigned to the design agent, the contrac- 
tor, or an independent third party. If feasible, an independent 
third party should be selected for objectivity. 

The verification methods should include analysis, measure- 
ment and inspection, demonstration, and functional testing. 
The specific methods employed at each interface will depend 
on the type of feature and the production sequence. Compliance 
should be verified at the highest practical assembly level. To 
preclude fabrication beyond the point where verification can be 
performed, an integrated inspection, measurement, and dem- 
onstration test outline of both hardware and software should be 
developed. This verification test outline will provide a sched- 
ule, tied to production, that allows all interface requirements to 
be verified. The resultant data and inspection sheets should 
become part of the verification data in the history jacket 
retained by the contractor for NASA. 

2.10 Training 2 

1 . What is the purpose of interface control? 

A. To define interfaces 

B. To ensure compatibility between interrelated equip- 
ment 

C. To provide an authority to control interface design 

D. All of the above 

2. How is an interface identified? 

A. By boundaries between functional areas 

B. By functional analyses of performance requirements 

C. By design features of a component that can affect the 
design features of another component 

3a. How can interfaces be categorized? 

A. Mechanical, electrical, software, and services 

B. Electrical/functional, mechanical/physical, software, 
and supplied services 

C. Electrical, physical, software, and supplies 

3b. What is one method of assigning an interface to one of the 
four basic categories? 

A. Functional flow block diagram 

B. Timeline analysis 

C. A- squared diagram 

4a. How can an interface be documented? 

A. By drawing format 

B. By specification format 

C. By both of the above 


4b. Who approves the interface control document? 

A. Designer or manager 

B. Owners of both sides 

C. Both of the above 

4c. Who ensures compliance with the approved ICD? 

A. Designer or manager 

B. Owners of both sides 

C. Project manager 

5a. What is a steady-state interface? 

A. A single set that remains constant for the life of the 
project 

B. A multiple-set suite that reconfigures during specific 
events in the life of the system 

5b. Give an example of a steady-state interface. 

A. An interplanetary probe 

B. A lunar base 

5c. What features make this a good example of a steady-state 

interface? 

A. The basic structure of the spacecraft would remain the 
same from assembly for launch throughout the life of 
the experiment. 

B. An initial base would be established and subsequently 
made more complex with additional structures and 
equipment delivered by subsequent lunar flights. 

6a. How should an ICD custodian be selected? 

A. Percentage of ownership of the interface 

B. Relative investment of interface sides 

C. An objective point of view 

6b. What criteria should be used to select a custodian? 

A. Integration or U.S. center, flight hardware or software, 
flight sequence, host or user, complexity, behavior, 
and partitions 

B. Integration hardware, sequence user, and partitions 

6c. What scoring system can be used for these criteria? 

A. Zero to 1 .0, verbal consensus, unbiased survey, and 
partition evaluation analysis 

B. One to 100, priority ranking, and voting 

7a. What is the purpose of an ICD compatibility analysis? 

A. Demonstrates definitions and provides mathematical 
analysis 

B. Demonstrates completeness of an interface definition 
and provides a record that the interface has been 
examined and found to be compatible 
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Answers are given at the end of this manual. 
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7b. What are the four categories that require interface 
analysis? 

A. Electrical/functional, mechanical/physical, supplied/ 
services, and hydraulic/pneumatic 

B. Electrical/functional, mechanical/physical, software, 
and supplied services 

7c. The hardware for mounting the satellite vehicle (SV) 
adapter to the Titan IV Centaur is shown in figures 2.1 
to 2.3. 

A. Is there sufficient data to perform a compatibility 
analysis? 

i. Yes ii. No 

B. Can the Jet Propulsion Laboratory specify the SV 
adapter ring? 

i. Yes ii. No 

C. What items need to be bracketed? 

i. Shear pin material and SV attachment view 

ii. SV panel and view C-C 

8a. What does a bracket on an ICD represent? 

A. Verification of design compliance 

B. An interface problem 


8b. What interface deficiency rating does a bracket discrep- 
ancy have? 

A. S & MA impact A > 1 or understanding of risk B > 2 

B. S & MA impact A < 1 or understanding of risk B < 2 

9a. How are mating sides of an ICD interface verified? 

A. Testing or measurement to meet requirements 

B. Analysis, measurement or inspection, demonstration, 
and functional testing 

9b. What does the verification test outline provide? 

A. Schedule, tied to production, that allows interface 
requirements to be verified 

B. Process controls, tied to manufacturing, for meeting 
schedules 

9c. Where is the resultant test and inspection data stored? 

A. Contractor files for use by an independent third party 

B. History jackets for use by NASA 
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Figure 2.2. — Titan IV and satellite vehicle orientation. 
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Figure 2.3. — Titan IV and satellite vehicle adapter ring. 








Chapter 3 

The Process: Through the Design Phases 


Interface control should be started when a program begins. 
This process eventually will define all interface design and 
documentation responsibilities throughout the life cycle of the 
program. Each program phase from concept development to 
project construction is directly related to the maturity level of 
interface control. 


3.1 Program Phases 

3.1.1 Concept Definition 

During the system engineering concept definition phase 
(from fig. 1.1), basic functional areas of responsibility are 
assigned for the various pieces of equipment that will be 
employed by the project (electrical power, environment con- 
trol, propulsion, etc.); see figure 3.1. At this point the design 
responsibilities of the responsible organization and related 
contractor (if chosen) should be defined to establish a set of 
tiered, traceable requirements. From these requirements the 
interfaces to be designed are identified by category (electrical/ 
functional, mechanical/physical, software, and supplied ser- 
vices) and by type of data that must be defined. This categori- 
zation will include a detailed review of each requirement to 
determine which requirements or features will be controlled by 
the interface control process. (What is important for this item to 
fulfill its intended function? On what interfacing equipment is 
this function dependent?) Once the interfaces to be controlled 
are selected, the formal procedures for interface control need to 
be established. These procedures include identifying the par- 



• Assign basic functional areas of responsibility. 

• Define design responsibilities. 

• Categorize interfaces. 

• Define interfaces to be controlled. 

• Establish formal interface control procedures. 

• Disseminate scheme, framework, traceability. 

Figure 3.1. — Establishment of interface control 
process during concept definition. 


ticipants responsible for the interface control documentation, 
the approval or signoff loop for documentation, and the degree 
to which all participants have to adhere to interface control 
parameters and establishing a missing design data matrix, 
change procedures, etc. (See section 3.2.) 

Early development of the interface process, products, and 
participants provides a firm foundation for the design engineer 
to use the correct information in designing his or her portion of 
an interface. It minimizes the amount of paper to be reviewed, 
shortens the schedule, and concentrates the efforts of the 
designer on his or her area of responsibility. 

Initial selection of interfaces generally begins with listing of 
all pieces of equipment in a system and then identifying the 
extent of interrelation among them. One tool used to help in this 
process is the ^-squared diagram. Details of this process can be 
found in reference 4. The A-squared diagram was initially used 
for software data interfacing; however, some centers are using 
it for hardware interfaces. If the diagram is not polarized 
initially (input/output characteristics not labeled), it is a conve- 
nient format for identifying equipment interfaces and for cat- 
egorizing them. An example of this form is shown in figure 3.2. 
This diagram can be further stratified to identify the interfaces 
for each of the categories; however, detailed stratification is 
best applied to electrical/functional, software, and supplied 
services interfaces. Using the A- squared diagram permits an 
orderly identification and categorization of interfaces that can 
be easily shown graphically and managed by computer. 

By the end of this phase the basic responsibilities and 
management scheme, the framework for the interface control 
documentation, and the process for tracking missing interface 
design data (see section 3.2.2) should be established and 
disseminated. 

3.1.2 Requirements Definition 

During the requirements definition phase (fig. 3.3; from 
fig. 1.1), the definitions of the mission objectives are completed 
so that each subsystem design can progress to development. 
Here, the technology to be used in the project will be defined to 
limit the risk associated with the use of new, potentially 
unproven technologies. Defining requirements and baselining 
interface documents early in the design process provides infor- 
mation to the designer needed to ensure that interface design 
is done correctly the first time. Such proactive attention to 
interfaces will decrease review time, reduce unnecessary 
paperwork, and shorten schedule times. By the end of require- 
ments definition all interface control documents should be 
prepared, interfaces defined to the most detailed extent pos- 
sible, and ICD’s presented for baselining. 
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Figure 3.2. — N-squared diagram for orbital equipment (Entries not polarized.) 


Baselining is the act by which the program manager or 
designated authority signs an ICD. That signature establishes 
the ICD as an official document defining interface design 
requirements. The term “baselining” is used to convey that the 
ICD is the only official definition and that this officiality comes 
from the technical management level. Not only is the initial 
version of the ICD baselined, but each subsequent change or 
update to an ICD is also baselined. 

The baselined version of the ICD will identify (by a “void”) 
any missing design data that cannot be included at that time. 
Agreed-to due dates will be noted on the ICD for each data 
element required. Each void will define the data required and 
specify when and by whom such data will be supplied. Where 
possible, the data to be supplied should be bounded initially on 
the ICD. These bounds will be replaced by detailed data when 
the void is filled. The initial bounds give the data user (the other 
side of the interface) a range that can be used without risk, until 
the detailed data are supplied. Establishing these voids on 
ICD’s provides a means of ensuring that interface design data 
are supplied when they are required by the data user. Yet it 
allows design freedom to the data supplier until the data are 
needed. A recommended form for use in identifying the data 
needed is shown in figure 3.4. The criteria for choosing due 
dates are discussed in section 3.2. 



• Define technologies to be used. 

• Define and categorize all interfaces. 

• Prepare all interface control documents. 

• Identify all voids and assign both 
responsibilities and due dates. 

• Bound voids when possible. 

• Baseline interface documents. 

Figure 3.3. — Development and control of 
interfaces during requirements definition. 
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Interface Design Data Required (IDDR) 


(Drawing/document number -4- Void number) 


Data required: Brief description of information needed 
to define interface element currently 
tacking details 

Data supplier (Project center/code/contractor) 

Data user(s): (Project center/code/contractor) 


Date due: (Date design data are needed, either actual 
date or a period of time related to a specific 
milestone. 


Figure 3.4. — Format for interface design data required (IDDR). 


Interface Design Data Required (IDDR) 
Program Status Report 


Drawing/doc # 

Sheet/page 

Short title 

Supplier^) 

User(s) 

Due date 

Remarks 

IDDR# 

/Zone 

Data required 

Center/code/ 

contractor 

Center/code/ 

contractor 

Yr/Mo/Day 
















Figure 3.5. — Format for monthly report on IDDR status. 


Documents should be baselined as early as possible, as soon 
as the drawings contain 10% of the needed information. The 
significance of early baselining is that both sides of the interface 
have the latest, most complete, official, single package of 
information pertaining to the design of the interface. 

The package includes all agreed-to design data plus a list of 
all data needed, its current level of maturity, and when it is to 
be supplied by whom to whom. 


Technical information voids in interface documents must be 
accounted for and tracked. Otherwise, there is no assurance that 
the needed information is being provided in time to keep the 
design on schedule. The status of these voids must be reported, 
and the owners of the interface-design-data-required forms 
(IDDR’s) must be held responsible for providing the needed 
information. It is recommended that the status be reported 
monthly to all parties having responsibility for the interfaces. 
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A consolidated report is the most efficient, consumes the least 
paper and mail services, and allows the program manager to 
track areas important to the integration of the system compo- 
nents. The basic form shown in figure 3.5 is recommended for 
reporting and tracking IDDR’s. 

3.1.3 Systems Integration 

The interface control program continues to be active during 
the systems integration phase (fig. 3.6; from fig. 1.1). Design 
changes that establish a need for a new interface will follow the 
interface control change procedures as defined in section 3.2. 

Proposed design changes that affect existing interfaces are 
not given final approval until all participants’ and the cognizant 
center’ s baselinings have been received through the ICD change 
notice system. 

During the various design reviews that occur in the full-scale 
engineering development phase, special attention should be 
given to design parameters that if altered, would affect inter- 
faces controlled by the ICD. It is strongly recommended that 
each design activity denote, on design and manufacturing 
documentation at the preliminary design review, through a 
bracket or some highlighting system, those features and char- 
acteristics that would affect an interface (see section 2.8). At the 
critical design review all voids should be resolved and all 
detailed design drawings should comply with interface control 
documentation (see section 2.9). 



• Manage and satisfy voids. 

• Invoke use of brackets on design drawings. 

• Ensure resolution of voids by the time of critical 
design review. 

• Verify compliance of design documentation with 
ICDs. 

Figure 3.6. — Development and control of interfaces 
during systems integration. 


3.2 Preparing and Administering 
Interface Control Document 

3.2.1 Selecting Type of Interface Control Document 

A drawing, a specification, or some combination format 
should be selected for the ICD on a case-by-case basis. The 
drawing format generally is preferred when the ICD has fea- 
tures related to physical dimensions and shapes. The specifica- 
tion format is preferred when the ICD needs tables and text to 
describe system performance. Combinations are used when 
both dimensions and tables are needed. Members of the 
coordinating activity responsible for preparing the ICD deter- 
mine the format, which is approved by the appropriate project 
authority. Examples of drawing formats are given in appen- 
dixes A and B. 

The level of detail shown on the ICD varies according to the 
type and degree of design dependency at the interface being 
controlled. The ICD should clearly identify and control inter- 
faces between designs and enable compatibility to be demon- 
strated between the design areas. The key to a useful ICD is 
limiting the detail shown to what is required to provide compat- 
ibility. Any unnecessary detail becomes burdensome and may 
confuse the contractors responsible for designing the mating 
interface. Again , the ICD should, at a minimum define and 
illustrate physical and functional interface characteristics in 
sufficient detail that compatibility , under worst-case toler- 
ances , can be determined from the ICD alone ; or it should 
reference applicable revisions of detailed design drawings or 
documents that define and bracket or identify features, charac- 
teristics, dimensions , etc., under worst-case tolerances, such 
that compatibility can be determined from the bracketed 
features alone. 

3.2.2 Tracking and Resolving Missing Interface 
Design Data 

Missing interface data should be identified on the ICD, and 
the ICD should control the date for its submission. The notation 
identifying the missing data should indicate the specific data 
required, how the data are being tracked for resolution, when 
the data are needed by the interfacing design agent, and by what 
date the required data will be supplied. Establishing data- 
required notations (or voids) on ICD’ s helps ensure that inter- 
face design data will be supplied when needed; yet it allows 
design freedom to the data supplier until the due date. Every 
attempt should be made to establish realistic due dates and to 
meet that schedule unless there is a valid and urgent need to 
change a due date. 

These criteria and procedures should be followed in estab- 
lishing, reporting, and managing data due dates: 
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1. Choose the due date as the date when the data user will 
start to be affected if agreed-upon or baselined data have not 
been received. 

2. When establishing a due date, allow time to process and 
authenticate a change notice to the ICD (i.e., once the due date 
has been established, include a period of time to establish that 
due date for the data supplier). 

3. The custodian responsible for the ICD should periodi- 
cally, as determined by the appropriate project authority, 
prepare and distribute a report on the status of all missing design 
information for all project activities. The report should contain 
the following information: 

a. Identification of the data element needed, consisting of 
the ICD number, the date, and a two- or three-digit 
number that provides a unique identifier for the data 
element 

b. A short title for the ICD 

c. The activity that requires the data 

d. The date when the missing data are to be supplied or 
the period of time after the completion of a program 
event or milestone when the data are to be supplied 

e. The activity from which the data are due 

f. The status of the data required (i.e., late data, data in 
preparation, or change notice number) 

g. A description of the data required 

3.3 Initial Issuance of ICD 

The first issue of an ICD should be a comment issue. The 
comment issue is distributed to participating centers and con- 
tractors for review and comment as designated in the interface 
responsibility matrix (fig. 3.7). 

The interface custodian generates the responsibility matrix 
for ICD’s. The matrix specifies the center and contractor 
responsibilities for baselining, review and comment, and tech- 
nical approval. The matrix lists all ICD’s applicable to a 
particular program. Distribution of the ICD’s can then be 
controlled through this matrix as well. 

The review and comment process is iterative and leads to 
agreement on system interface definitions and eventual approval 
and baselining of the ICD. See figure 3.8 for a flow diagram of 
the issuance, review and comment, and baselining procedures 
for ICD’s. Concurrent distribution of the comment issue to all 
participants minimizes the time needed for review and subse- 
quen. resolution of differences of opinion. 

3.4 Document Review and Comment 

As designated in the ICD responsibility matrix, all centers 
and contractors should submit technical comments through the 


appropriate authority to all other activities with review and 
comment responsibilities for the particular ICD and to the ICD 
custodian. 

Technical comments by all activities should be transmitted 
to the custodian as soon as possible but not later than 30 
working days 4 from receipt of the comment issue. If the 
comment issue is technically unacceptable to the Government 
authority or the interfacing contractor, the rationale for 
unacceptability should be explained, including technical and 
cost effects if the interface definition is pursued as presented. 

3.4.1 Resolving Comments 

The ICD custodian collects review comments and works in 
conjunction with project management for comment resolution 
until approval is attained, the comment is withdrawn, or the 
ICD is cancelled. Information on comments and their disposi- 
tion and associated resolution should be documented and 
transmitted to all participants after all comments have been 
received and dispositioned. Allow two weeks 4 for participants 
to respond to the proposed resolution. Nonresponses can be 
considered concurrence with the resolutions if proper 
prenotification is given to all participants and is made part of the 
review and comment policy. 

When comments on the initial comment issue require major 
changes and resolution is not achieved through informal com- 
munications, an additional comment issue may be required 
and/or interface control working group (ICWG) meetings may 
need to be arranged. 

3.4.2 Interface Control Working Group 

The ICWG is the forum for discussing interface issues. 
ICWG meetings serve two primary purposes: to ensure effec- 
tive, detailed definition of interfaces by all cognizant parties, 
and to expedite baselining of initial ICD’s and subsequent 
drawing changes by encouraging resolution of interface issues 
in prebaselining meetings. A major goal of interface control 
should be that baselining immediately follow a prebaselining 
ICWG meeting. 

All ICWG meetings must be convened and chaired by the 
cognizant project organization. The project can choose a con- 
tractor to act as the chair of an ICWG when Government 
commitments are not required. In all cases the ICWG members 
must be empowered to commit the Government or contractor to 
specific interface actions and/or agreements. In cases where a 
contractor is ICWG chair, the contractor must report to the 
Government any interface problems or issues that surface 
during an ICWG meeting. 


4 The times assigned for commenting activities to respond are arbitrary and 
should be assigned on the basis of the schedule needs of the individual 
programs. 
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Figure 3.8. — Flow of interface control document production. 


The ICWG chair prepares the ICWG meeting minutes or 
designates one of the meeting participants for this task. The 
minutes should include discussions of problems, agreements 
reached, decisions made, and action items. The ICWG chair 
also ensures that any updated interface control documentation 
reflecting the ICWG discussions is distributed within the 
timeframe agreed to by the affected participants. 

3.4.3 Approval/SignofF Cycle 

The management plan for the project assigns responsibility 
for each piece of equipment to a specific project authority and 
its contractor. The signoff loop for each ICD reflects this plan 
and can be related to the project and the origin of each design 
requirement. For each ICD, then, the signoff loop follows the 
sequence of technical approval by the contractors first and then 
by the appropriate project authority. 

3.4.4 Technical Approval 

The appropriate project authority and the primary and asso- 
ciate organizations with an interest in a particular ICD are listed 
in the responsibility matrix. They each sign the ICD to signify 
technical agreement and a readiness to contractually invoke its 
requirements. 


3.4.5 Baselining 

Interface control documents are baselined when the owners 
of both sides of the interface at the next level up in the program 
structure come to technical agreement and sign the document. 


3.5 Change Notices 

The procedure for initiation, review, technical approval, 
baselining, and distribution of changes to project ICD’s 
(fig. 3.9) should conform to the following guidelines. 

3.5.1 Initiating Changes 

Any project activity should request a change to an ICD when 

1 . Data are available to fill a void. 

2. Information contained in a data-required note needs to be 
modified. 

3. Additional data are needed (i.e., a new data requirement 
has been established). 

4. A technical error is discovered on the ICD. 
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Figure 3.9. — Development and flow of change notices in the ICD revision process. 











5. An equipment design change and a system or equipment 
rearrangement are proposed to improve performance, 
reduce cost, or expedite scheduled deliveries that would require 
changes to an interface or creation of new interfaces. 

3,5.2 Requesting Changes 

All requests for changes should be submitted to the organi- 
zation responsible for maintaining the ICD, with copies to all 
activities that will review the resultant change notices and to the 
appropriate project authority. If baselining is needed in less 
than 30 days, a critical change should be requested. All requests 
for changes should be submitted in a standard format that 
includes the following items: 

1 . Originator’s identification number — It is used as a refer- 
ence in communications regarding the request and should 
appear on resulting change notices 

2. Originating activity — originating project and code or 
originating contractor 

3. Point of contact — name, area code, telephone number, 
facsimile number, and e-mail address of the person at the 
originating activity to be contacted regarding the request 

4. Document affected — number, revision letter, and short 
title of each ICD that would be affected by the change 

5. Number of data voids (if applicable) — number of data 
requirements for which data are being provided 

6. Urgency — indication of whether this change is critical or 
routine (project decides whether to use critical route) 

7. Detailed description of change — a graphic or textual 
description of the change in sufficient detail to permit a clear 
portrayal and evaluation of the request. Separate descriptions 
should be provided when more than one ICD is affected. 

8. Justification — concise, comprehensive description of the 
need and benefit from the change 

9. Impact — concise, comprehensive description of the ef- 
fect in terms of required redesign, testing, approximate cost, 
and schedule effects if the requested change is not approved; 
also the latest date on which approval can occur and not affect 
cost or schedule 

10. Authorizing signature of the organization requiring the 
change 

Upon receipt of a change request to an ICD, the ICD 
custodian coordinates the issuance of a proposed change notice. 
First, the ICD custodian evaluates the technical effect of the 
proposed change on the operation of the system and mating 
subsystem. If the effect of the change is justified, the ICD 
custodian generates and issues a change notice. If the justifica- 
tion does not reflect the significance of the change, the ICD 
custodian rejects the request, giving the reason or asking for 
furtherjustification from the originating organization. The ICD 
custodian evaluates an acceptable change request to determine 
whether it provides data adequate to generate a change notice. 


The proposed change notice describes the specific changes 
(technical or otherwise) to the ICD in detail by “from-to” 
delineations and the reasons for the changes, as well as who 
requested the changes and how the change request was trans- 
mitted (i.e., by letter, facsimile, ICWG action item, etc.). 

3.5.3 Proposed Change Notice Review and 
Comment Cycle 

The review and comment cycle for proposed changes to 
ICD’ s should follow the same system as that used for the initial 
issuance of the ICD (see sections 3.3 and 3.4). 

3.5.4 Processing Approved Changes 

The baselined change notice should be distributed to all 
cognizant contractors and project parties expeditiously to prom- 
ulgate the revised interface definition. The master ICD is 
revised in accordance with the change notice, and copies of the 
revised sheets of the ICD are distributed (see sections 3.3 and 
3.4). Approval of the change by the project constitutes author- 
ity for the cognizant organization to implement the related 
changes on the detailed design. 

3.5.5 Distributing Approved Changes 

The custodian distributes the baselined change notice to all 
cognizant centers and contractors to expeditiously promulgate 
the revised interface definition. The master ICD is then revised 
in accordance with the change notice, and copies of the revised 
ICD sheets are distributed as was the change notice. 
The responsibility matrix (fig. 3.7) can be used to identify the 
distribution of change notices as it was used for the distribution 
of the ICD’s. 

3.5.6 Configuration Control Board 

During development the project’s configuration control 
board is responsible for reviewing and issuing changes to the 
configuration baseline. The board reviews all class I engineer- 
ing change proposals to determine if a change is needed and to 
evaluate the total effect of the change. The configuration 
control board typically consists of a representative from the 
chairman, the project management office, customers, engineer- 
ing, safety assurance, configuration management (secretary), 
fabrication, and others as required. 

Changes to configuration items can only be effected by the 
duly constituted configuration control board. The board first 
defines a baseline comprising the specifications that govern 
development of the configuration item design. Proposed changes 
to this design are classified as either class I or class II changes. 
Class I changes affect form, fit, or function. However, other 
factors, such as cost or schedule, can cause a class I change. 
Class I changes must be approved by the project before being 
implemented by the contractor. 
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All other changes are class II changes. Examples of class II 
changes are editorial changes in documentation or hardware 
changes (such as material substitution) that do not qualify as 
class I changes. Project concurrence, generally, is required for 
the contractor to implement class II changes. Government plant 
representatives (Defense Contracts Administration Services 
(DCAS), Navy Programs Resident Office (NAVPRO), and Air 
Force Programs Resident Office ( AFPRO) usually accomplish 
these tasks. 

3.5.7 Closing the Loop 

A wide range of methods are available for verifying by test 
that the design meets the technical requirements. During the 
definition phase analysis may be the only way of assessing what 
is largely a paper design. Typical methods are testing by 
similarity, analysis, modeling, and use of flight-proven compo- 
nents; forecasting; and comparison, mathematical modeling, 
simulation modeling, and using flight-proven experience and 
decisions. The actual methods to be used are determined by the 
project office. Each method has associated costs, requires 
development time, and provides a specific level of performance 
verification. The Government and industry managers must 
carefully trade off program needs for performance verification 
with the related costs. 

If any demonstrated or forecast parameter falls outside the 
planned tolerance band, corrective action plans are prepared by 
the contractor and reviewed by the Government project office. 
Each deviation is analyzed to determine its cause and to assess 
the effect on higher level parameters, interface requirements, 
and system cost effectiveness. Alternative recovery plans are 
developed showing fully explored cost, schedule, and technical 
performance implications. Where performance exceeds re- 
quirements, opportunities for reallocation of requirements and 
resources are assessed. 

Although functional and performance requirements are con- 
tained in the appropriate configuration item specification, the 
definition, control, and verification of interface compatibility 
must be handled separately. Otherwise, the volume of detail 
will overwhelm both the designers and managers responsible 
for meeting the functional and performance requirements of the 
system. Early establishment of the interface definition and 
control process will provide extensive savings in schedule, 
manpower, money, and paper. This process will convey pre- 
cise, timely information to the interface designers as to what the 
designer of the opposing side is committed to provide or needs 
and will subsequently identify the requirements for verifying 
compliance. 

Whether the interface is defined in a drawing format or in a 
narrative format is at the discretion of the program. What is of 
primary importance is that only the information necessary to 
define and control the interface should be on these contractural 
documents to focus the technical users and minimize the need 
for updating information. 


Appendix G provides seven ICD guidelines that have been 
used by many successful flight projects and programs to pro- 
vide such a focus on the interface definition and control 
process. 

3.6 Training 2 

1 a. When should the ICD process be started? 

A. Concept definition B. Requirements definition 
C. Systems integration 

1 b. What are the benefits of early development of the ICD 
process? 

A. Assigns basic areas of responsibility 

B. Provides firm foundation for design, minimizes 
paper, shortens schedule, and concentrates efforts 

lc. What tool can be used to list equipment and identify their 
interrelations in a system? 

A. Prechart B. TV-squared diagram 

2a. What should be done in the ICD process during require- 
ments definition? 

A. Define mission objectives 

B. Define technology and interfaces and present for 
baselining 

2b. What is baselining? 

A. The designated authority signing an ICD 

B. The only official definition 

2c. How are voids in an ICD accounted for and tracked? 

A. Procedure or administration report 

B. Monthly program status report on interface design 
data required 

3a. What should be done in the ICD process during develop- 
ment? 

A. Manage voids, invoke brackets, resolve voids, and 
verify compliance 

B. Control interface developments 

3b. How should proposed design changes be handled? 

A. Discussed at critical design review 

B. Discussed and approved by all participants 

3c. What should be given special attention? 

A. Design parameters that affect controlled ICD 

B. Manufacturing documentation 


^Answers are given at the end of this manual. 
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4a. When is the drawing format used for an ICD? 

A. To describe the type and nature of the component 

B. To describe physical dimensions and shapes 

4b. When should a specification be used? 

A. To describe performance with tables and text 

B. To describe a software function 

4c. What is the key to providing a useful ICD? 

A. Give as much detail as possible 

B. Limit the detail to what is necessary to demonstrate 
compatibility 

5a. What is the purpose of the initial issue of an ICD? 

A. Issuance, review, comment, and baselining 

B. Review and resolution of differences of opinion 

5b. Who is responsible for controlling the flow of an ICD? 

A. Contractor 

B. Custodian 

6a. Who should review ICD’s? 

A. Organizations designated in the responsibility 
matrix 

B. ICD custodian 

6b. How are comments resolved? 

A, By the project office 

B. By project management and custodian working for 
resolution and approval or the comment being with- 
drawn 

6c. Where are interface issues discussed? 

A. Project office 

B. Interface control working group 


6d. Who approves and baselines an ICD? 

A. Projects at the next level up in program structure 

B. The project office 

7a. When should a project activity request a change to an ICD? 

A. At the custodian’s request 

B. When data are available, requirements need change, 
an error is discovered, or the design changes 

7b. What items should be included in a change notice request? 

A. Identification number, activity, contact, document 
affected, number of data voids, urgency, descrip- 
tion, justification, impact, and authorizing signature 

B. Those established by the ICWG 

7c. Who evaluates and issues a proposed change notice? 

A. ICD custodian 

B. Project office 

7d. What does a proposed change notice describe? 

A. Specific changes (from-to), reasons, and the 
requestor 

B. Project notices 

It. How is a change notice approved and distributed? 

A. By the project authority to all cognizant parties 

B. By all cognizant parties to the contractors 


National Aeronautics and Space Administration 
Lewis Research Center 
Cleveland, Ohio, 44135, July 1995. 
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Appendix A 

Electrical/Functional Interface Example 


This appendix illustrates elements of a telemetry drawing 
interface control document showing control of waveform 
parameters and data rates. This interface example depicts data 
transfer between a guidance system electronics assembly and a 
launch vehicle telemetry system. The basic drawing (fig. A. 1 ) 
covers the isolation elements of the guidance system, the jack 
and pins assigned, and shielding and grounding on the guidance 
side of the interface. Bus functions are named (e.g., guidance 
telemetry data 1 (parametric)), and the shielding requirements 
through to the first isolating elements of the telemetry system 
are provided (see notes on fig. A.l). 

Table A.l contains the details to be controlled for each bus 
function. Signal source (electronics assembly) and destination 
(telemetry system) are identified. The waveform (fig. A.2) and 
its critical characteristics (table A.2) are provided, as well as 
data rates and sources and load impedances. Telemetry load 
impedance is further described by an equivalent circuit (see 
note 3 on fig. A.l). 

The final value of pulse minimum amplitude is missing in 
this example. This is noted by the design-data-required (DDR) 


callout in table A.2 and the accompanying DDR block (fig. 
A. 3). The DDR block notes that the responsible parties have 
agreed on an amplitude band with which they can work until the 
guidance design becomes firm. However, there is also a date 
called out that indicates when (45 days after preliminary design 
review) the telemetry contractor must have the data to be able 
to complete design and development and deliver the telemetry 
in time to support launch vehicle flight. 

The parameters called out in this example are only those 
needed to control the design of either side of the interface 
through the first isolating element. Also note that only the 
shielding and wire gage of the launch vehicle cabling between 
the two systems are provided. Only pin numbers for the 
guidance side of the interface are called out and controlled. 
Connector types and other pertinent cable specifications are as 
per a referenced standard that applies to all launch vehicle 
cabling. In this case the same pulse characteristics apply to each 
of the functions covered; however, table A.2 is structured to 
permit variation for each function if the design should dictate 
different values for the characteristics of each function. 
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Function Guidance Launch vehicle 
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Figure A.1 . — Guidance/launch vehicle telemetry interface. 
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Pulse duration 



Notes: 

1 . The interpulse period shall be the period from 1 50 ns after the trailing edge of 
a pulse until 1 00 ns prior to the leading edge of the subsequent pulse. 

2. The reference level shall be the average voltage for the last 200 ns of the 
interpulse period. 

3. The no-transmission level shall be 0 V differential at the guidance/launch vehicle 
interface using the test load specified in table A.2. 

4. Shielding depicted represents the telemetry shielding requirements only. For 
cable routing see void #01. Telemetry shielding shall be carried through all 
connectors between the electronic assembly and the telemetry subsystem. 

5. A radiofrequency cap shall be provided on electronic assemblies in all launch 
vehicles in lieu of this connector. 

Figure A.2. — Guidance data pulse characteristics. 
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Table A.2.— REQUIRED PULSE CHARACTERISTICS AND TEST PARAMETERS 


Pulse 

characteristics 
(see fig. A.2) 

Guidance telemetry 

Data 1 

Data 2 

Bit 

synchronization 

Frame 

synchronization 

Data 1 word 
synchronization 

Data 2 word 
synchronization 

Pulse duration 
Minimum amplitude 
Maximum amplitude 
Rise time 
Fall time 
Undershoot 
Reference level offset 
Noise 

Receiver susceptibility 
Test parameters: 

Test load 
Receiver 
susceptibility 

255 + 50 ns 
9 ± 2 V (see V027) 

15 V 

75 ns maximum 
1 25 ns maximum 
2.5 V maximum 

0 to -4.5 V relative to no-transmission level 
1 .4 V maximum peak to peak 
2.0 V minimum 

75 H±5% resistive 
2.0 V minimum 


DDR No. 3288399-V027 

Data required: 

Guidance subsystem waveform parameter data (minimum amplitude 
value to replace coordinated temporary amplitude band currently on 


ICD-3288399) 

Data supplier: 

SP-201 2/guidance telemetry steering committee 

Data user(s): 

SP-2732/launch vehicle telemetry contractor/interface coordinator 

Date due: 

45 days following guidance preliminary design review 


Figure A.3. — Typical design data required for table A.2. 
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Appendix B 

Mechanical/Physical Interface Examples 


B.l Mechanical Interface for 
Distributed Electrical Box 

Figure B.l is an example of an interface development docu- 
ment (IDD) that, from initial inspection, appears to be fairly 
complete. This figure contains a great amount of detail and just 
about everything appears to be dimensioned. However, closer 
examination will reveal serious shortcomings. 

First, the basic function of the interface must be defined. The 
box depicted must be capable of being removed and replaced on 
orbit, in many cases outside the crew habitat. In some cases it 
is to be removed and replaced robotically. The box slides along 
the L-shaped bracket held to the support structure by three 
mounting bolts labeled “bolt 1 44 bolt 2,” and “bolt 3.” As the 
box slides along the L-shaped bracket from left to right in the 
figure, some piloting feature on the box connectors engages the 
connectors mounted to the support structure by the spring- 
mounted assembly, and the connector engages fully when the 
lead screw is completely engaged. 

1. The initial interface area to be examined is that of the 
L-shaped bracket to the support structure (i.e., the interface of 
the three mounting bolts) . The interface is being examined from 
the perspective of the designer of the support structure. Does 
figure B. 1 contain enough information for a mating interface to 
be designed? (The area of interest has been enlarged and is 
presented as figure B.2.) 

a. The dimensions circled in figure B.2 and lettered a, b, 
c, and d locate the position of the mounting bolts 
relative to the box data. The following pertinent 
differences are noted concerning this dimensioning: 

i. Dimension a locates the holes relative to a “refer- 
ence datum for coldplate support structure,” but 
the datum is not defined on the drawing. Is it a line 
or a plane? What are the features that identify/locate 
the datum? What is the relationship of this datum to 
other data identified on the IDD (data A, B, and D)? 
This information is required so that the designer 
of the support structure can relate his or her 
interface features easily to those of the box IDD* 

ii. The IDD states that the tolerances on three-place 
decimals is ±0.010. Dimensions a, b, c, and d 
are three-place decimal dimensions and would, 
therefore, fall under this requirement. Elsewhere on 
the IDD a true position tolerance for bolt locations 
is indicated. A feature cannot be controlled by both 
bilateral and true positioning tolerancing. It must be 


one or the other. Considering the function of the 
mounting bolts — to locate the box relative to the 
electrical connectors, it has to be assumed 
that dimensions a, b, c, and d are basic dimensions. 
Interface control drawings cannot require the 
designer of the mating interface to assume any- 
thing. IDD’s must stand by themselves. 

b. Figure B.3 depicts initial details of mounting bolts 
for the L-shaped bracket. On first inspection there 
appears to be a great amount of detail. However, further 
examination shows that much of the detail is not related 
to interface definition. The interface is the bolt. Where 
is it relative to other features of the box? What is the 
relationship of bolts 1 and 2 to bolt 3 (datum C)? 
What is the thread of the bolt? How long is the bolt? 
The following data on the IDD are not required: 

i. Counterbore for bolt head 

ii. Diameter of bolt hole in bracket for bolts 1 , 2, 
and 3 

iii. Distance of bolt hole to first thread 

iv. The fact that there is a screw retaining ring 
Adding data not required for the interface , even if they 
are only pictorial , is expensive. It takes time for the 
organization to develop and present it, and it takes 
time for the designer of the mating interface to deter- 
mine that the information is not necessary and discard 
it. If the extraneous information stays on the IDD , it 
must be maintained (i.e , , changed if the design details 
change). Only the features of a design that affect the 
features of the design of the mating interfaces need 
be placed on the IDD. 

c. Once the unnecessary data are removed, what remains 
is shown in figure B.4. The data that remain are not 
complete and are unclear. The true position notations 
are indicated as being those for the “mounting inter- 
face for bolt,” suggesting that the true position applies 
to the hole in the support structure. However, since the 
IDD is basically covering the features of the box, it is 
assumed that these locations apply to the bolts on the 
box. It should not be necessary to have to make 
assumptions about data on an IDD or I CD. The 
document should stand by itself. 

The only other data left in figure B.4 are the callouts for 
the locking inserts. These callouts refer to the method 
used by the designer of the support structure for retaining 
the bolts. This IDD should not have this callout, since the 
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Figure B.1 . — Partial interface development document for multiuse electrical power interface box showing bolt locations. 
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Figure B.4. — Necessary details of mounting bolts. 
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Figure B.5. — Minimal interface definition. 


method used for retaining the bolts is not the responsibil- 
ity of the box designer. Generally IDD’s and ICD’s 
should not specify design solutions, especially when 
the design solutions are not the responsibility of the 
one specifying them. 

What is missing is how far the bolts protrude from the 
box. These data are required so that the designer of the 
support structure knows how deep to make the mating 
hole and how much of a mating thread must be supplied 
to grip the bolts on the box. 

Considering all of the above, figure B.5 represents 
what is really required (along with the locations and 
thread types already defined in fig. B . 1 ) to define the box 
side of the interface and for the designers of the support 
structure to design a compatible interface between the 
retaining bolts and the support structure. 


2. The next area to be examined is that of the connector 
interface. Since both parts of the connector are being provided 
by the box designer, the interface is the plate on which the 
connectors are attached to the support structure. Again, the 
question is. Does figure B.l contain enough information for a 
mating interface to be designed? The answer to that question is, 
Definitely not! The interface of the plate (holding the connec- 
tors) that mates with the support structure is identified as datum 
D. Again, there is no definition of this datum. Is it a plane 
passing through the three highest points of the plate or some 
other features of the connector plate? 

If a compatible mating interface is to be designed, the 
relationship between the surface to which the connector plate is 
attached and the surface to which the L-shaped bracket is 
attached must be known. None of these data are supplied in 
figure B.l. The following are data needed to establish this 
relationship: 
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a. The required perpendicularity of D to A 

b. The required parallelism of D to B 

c. The required angular relationship of the vertical centerline 
shown in view B-B with the vertical centerline shown in 
view A-A 

d. The pattern required for the four fasteners holding the 
connector plate to the support structure. View B-B does 
contain a dimension of 2.594 for a horizontal spacing of 
the lower two features but does not indicate that this 
dimension is applicable to the upper two fasteners. In 
addition, there is no dimension for the distance between 
the fasteners in the Z direction. 

e. The required relationship of the hole pattern for the 
connector plate relative to the box, namely, 

i. The location of the hole pattern above A in the Z 
direction 

ii. The location of the hole pattern relative to C in the 
X direction 

iii. The distance of datum D from C in the Y direction 
when the box is fully installed 

Since none of these data are identified as items to be determined 
(TBD’ s), it must be assumed either that the data are not required 
because the connectors can be mated properly with a great deal 
of misalignment or that the box designer did not recognize that 
this type of data is required. Designers never wish to freeze a 
design. The placement of design constraints in an ICD is 
basically freezing an area of a design or at least impeding the 
ability to change a design without that design being scrutinized 
at another level. Therefore, the tendency of designers is to 
disclose the minimum that they feel is necessary in the 
interface for the control process. This is the primary reason 
for the ICD custodian not to be organizationally a part of 
the design process. Yet the ICD custodian must have access to 
the design function of an agency or contractor organization to 
ensure the ready flow of the data required for proper interface 
definition. (Can interface compatibility be demonstrated from 
the ICD’s alone?) 

The ICD custodian must always test the data in interface 
documentation from the viewpoint of another design agent who 
must develop a compatible mating interface. 

The preceding discussion simplifies specification of the 
L-shaped bracket and the mounting bolts. This redefinition of 
the interface tied up loose ends and provided needed dimen- 
sions and callouts absent from the original document. These 
portions of the document can now be controlled more easily and 
related to a 100% mate design. 


B.2 Space Reservation and Attachment 
Features for Space Probe Onboard 
Titan IV Launch Vehicle 

Figure B.6 is an example of an ICD that defines the space 
envelope available onboard the Titan IV launch vehicle for a 
payload and the attachment feature details for the launch 
vehicle side of the interface. The intended payload is the 
Cassini Mission spacecraft. The Titan payload fairing, as 
would be expected, is defined. The other side of this envelope 
(i.e., the spacecraft) must also be defined to show compatibility. 
When the spacecraft dimensions are established, compatibility 
should be shown by a comparison of the two envelopes. The 
Titan documentation defines the available space reserved for 
equipment (i.e., a stay-out zone for the Titan launch vehicle 
items). Ideally, this ICD should define a minimum space 
available for the spacecraft. Therefore, if the spacecraft dimen- 
sions are constrained to a maximum size equal to the launch 
vehicle’s minimum, less a value for environmental effects, etc., 
then the two envelopes are compatible. 

Since interface data have been provided for the attachment 
details for the launch vehicle side of the interface, the design of 
the Cassini adapter for mounting to the Centaur launch vehicle 
at station -150.199 can be explained by using the Titan design 
data. 

The following key interface features have been established 
for this connection: 

1. Sheet 1 (fig. B.6(a)), note 5: Location of holes is estab- 
lished by a common master gauge tool with reference dimen- 
sions provided. 

2. Sheet 3 (fig. B.6(c)), section F-F: Bearing areas are to be 
flat within 0.006 (units), and per view G the maximum bearing 
area has been defined. 

3. Sheet 3 (fig. B.6(c)), view H: Shape and dimensions of the 
shear alignment pins have been established. 

4. Sheet 1 (fig. B.6(a)), note 4: How loads are to be transmit- 
ted is indicated. 

The following data elements missing from figure B.6 are 
mostly related to the lack of spacecraft design data: 

1. No apparent tracking of TBD’s. A tracking system 
should be in place at the beginning of ICD development 
Each TBD should have a unique sequential identifier with 
due dates and suppliers established. 

2. No revision block for tracking the incorporation of changes. 
Some type of revision record should be placed on each sheet. 
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Figure B.6. — Titan IV and space vehicle physical/envelope interfaces, (a) Notes and abbreviations, (b) Orientation view, (c) Section views. 














Figure B.6. — Continued, (b) Orientation view. 
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Figure B.6. — Concluded, (c) Section views. 







Upon exchange of design data relating to the Cassini probe it 
would be expected that the probe’s maximum envelope would 
be established and related to the data system of the Titan/ 
Centaur launch vehicle. 

This example is basically a one-sided interface. The Titan/ 
Centaur side of the interface is well defined, which is to be 
expected considering the maturity of the design. The tendency 
should be resisted, in cases like this, to ignore or place less 
emphasis on the definition and documentation of the mating 
interface, given the completeness of the launch vehicle side of 
the interface. The mating interface, namely, the spacecraft side, 
should be completely defined. Otherwise, the spacecraft de- 
signer will be signing up to design a compatible interface by 
agreeing with what the interface on the launch vehicle side 
looks like. Although this approach allows freedom to go off and 
“do independent things,” it lacks the degree of positive control 


needed for interface compatibility. The chances for an incom- 
patibility are much less if the spacecraft side of the interface is 
defined. Space vehicle data, stations, and fasteners must be 
identified and controlled. The designer of the space vehicle is 
then able to commit to the design and production of an interface 
that is defined. The launch vehicle designers can then verify 
that the spacecraft interface will mate with the launch vehicle 
available for the spacecraft. Therefore, if the spacecraft dimen- 
sions are constrained to a maximum size equal to the launch 
vehicle’ s minimum, less a value for environmental effects, etc. , 
then the two envelopes are compatible. 

Since interface data have been provided for the attachment 
details for the launch vehicle side of the interface, the design 
of the Cassini adapter for mounting to the Centaur launch 
vehicle at station -150. 1 99 can be explained by using the Titan 
design data. 
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Appendix C 

Software Interface Example: 

Definitions and Timing Requirements for Safety 
Inhibit Arm Signals 


Signal definition 

Centaur sequence 
control unit 
switch number 

Initiating event + time 

Persistence 

Function 

Satellite vehicle (SV) 
pyro unshort 
(primary) 

45 

Main engine cutoff 
(MECO) 2 + 3±0.5 sec 

3 ±0.5 sec 

Unshorts SV pyro capacitor banks 

SV latch valve 
arm (primary) 

33 

MEC02 + 10±0.5 sec 

3±0.5 sec 

Arms safety inhibit relay for SV 
main engines 

SV pyro unshort 
(secondary) 

89 

MEC02 + 15±0.5 sec 

3 ±0.5 sec 

Provides redundant unshort of SV 
pyro capacitor banks 

SV latch valve 
arm (secondary) 

88 

MEC02 + 17±0.5 sec 

3 ±0.5 sec 

Provides redundant arm of inhibit 
relay for SV main engines 

Radiofrequency 
monopropellant driver 
backup enable 

34 

Titan IV/Centaur 
separation + 24±0.5 sec 

3 ±0.5 sec 

Services backup (redundant to SV 
ground support equipment com- 
mand) enable of safety inhibit SV 
functions (radiofrequency sources 
and reaction control system thruster 
drivers) 
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Appendix D 

Supplied Services Interface Example 


This appendix provides a simplistic text-based example of a 
supplied services (air-conditioning and cooling water) inter- 
face control document with a typical design-data-required 
(DDR) block. This example contains elements condensed from 
a number of service documents originally used for a submarine 
weapons program; however, the principles contained herein are 
universally applicable to any complex system of interfaces. 
Page 1 of the ICD lists the DDR’s (table D.l) showing DDR 


numbers, location on the drawing, brief description, and due 
date. The DDR block (fig. D. 1 ) on the drawing expands on this 
information and identifies supplier, user, and time urgency of 
the data needed. The DDR numbering convention used here is 
“V09 = Void #09.” Preceding the void number with the ICD 
number provides a program-unique DDR number that is easily 
related to its associated ICD and easily maintained in a data 
base. 


TABLE D.l —DESIGN-DATA-REQUIRED SUMMARY 
AND LOCATOR 


Void 

number 

Location 

Description 

Date due 

V01 








V09 

Sheet 1, 
zone C-7 

Main heating 
and cooling 
(MHC) water 
schedule 

30 Days after 
authentication of 
data fulfilling 
DDR 5760242-V12 






DDR No. 1 4661 34-V09 

Data required: 

Heating and cooling (HC) system upper zone 
water schedule (supply water temperature versus 
environmental temperature) 

Data supplier: 

HC working group 

Data user 

Launch vehicle design agent 

Date due: 

30 days after authentication of data fulfilling DDR No. 
2543150-V12 


Figure D.l . — Typical design-data-required block. 
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The following pages present the kinds of data required to fully 
define the air-conditioning requirements for suites of equip- 
ment located in a launch control center. Table D.2 details 
conditioned-air distribution; table D.3 presents typical inter- 
face data required to ensure that a cooling water service is 
provided to electrical equipment and indicates requirements for 
the equipment before and after the incorporation of an engi- 
neering change. 

701. Launch vehicle control center services: 

A. Air-conditioning shall be provided with a dedicated 
closed-circuit system capable of supplying a mini- 
mum total flow of 12 820 scfm with a 50% backup 
capability. 

1. The conditioned air shall be distributed to each 
equipment flue as specified in table D.2. The distrib- 
uted conditioned air at the inlet to the equipment 
shall satisfy the following parameters: 

a. Temperature: The minimum temperature shall be 
65 °F and the maximum, 70 °F. 

b. Humidity: The maximum humidity shall be 75 
grains per pound of dry air. 

c. Working pressure: The working pressure shall 
be enough to overcome equipment pressure drops 
and to maintain positive pressure at the equip- 
ment outlet with respect to compartment ambi- 
ent pressure. A 10% minimum leakage rate in the 
compartment shall be assumed. 

d. Flow resistance: The system shall be able to over- 
come the pressure drop across the equipment (i .e. , 
from exit of orifice plate to top of equipment) as 
shown in table D.2. 

e. Flow profile: 

(1) The flow distribution for each flue shall be 
such that the flow velocity between the flue 
centerline and 1.3 in. from the edge of the flue, 
and (where equipment permits) 6 in. above the 
flue gasket, shall not be less than 80% of the 
achieved average flow velocity. The achieved 
average flow velocity must equal or exceed veloc- 
ity based on the minimum flow rate specified in 
table D.2. 

(2) Velocity profiling is not required for flues 
designated 301 through 310, 011 through 015, 
446BC, 405-2A, 405-2B, 405-6A, and 405-6B. 

f. Adjustment capability: The system shall provide 
flow adjustment from 0 to 300 scfm at each of the 
equipment flues requiring velocity profiling. 


g. Air quality: Air at the inlet to the equipment shall 
be equivalent to or better than air filtered through 
a 0.3-|xm filter with an efficiency of 95%. 

2. The closed-loop system shall have the capacity of 
removing 52.8 kW (minimum) of heat dissipated by 
equipment using closed-circuit conditioned air. This 
heat load includes 1.3 kW reserved for launcher 
equipment in the launch vehicle control center (see 
note 702 below). 

702. The system shall provide the capability of removing 
1 .65 kW minimum of heat dissipated by equipment by using 
compartment ambient air as a cooling medium while maintain- 
ing the compartment within specified limits. 

A. The ship shall take no action that eliminates the option 
for launcher equipment to use compartment ambient air 
or closed-circuit conditioned air for dissipating launcher- 
generated heat of 1 .3 kW. 

B. Heat dissipated to ambient air by equipment using 
closed-circuit conditioned air is not included. 

703. The system shall provide distribution trunks to equip- 
ment flues with total flow capacity as designated below for the 
conditions of table D.2: 


Trunk 

Minimum 

flow, 

scfm 

A 

2700 

B 

1620 

C 

2300 

D 

3400 

E 

1300 

F 

1500 


704. Flow at reference designations marked with an asterisk 
in table D.2 are to be considered flow reserve capabilities. 
These designated flues do not require verification of flow per 
table D.2 nor profiling per note 701.A.1 .e(l) until these flues 
are activated. The Government-furnished pipe assemblies and 
caps will be supplied for flues not activated. 

705. The minimum flow for flues 446BC and 447BC is 
100 scfm before change 30175 and 250 SCFM after change 
30175. 
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TABLE D.2. — CONDITIONED- AIR DISTRIBUTION 


Equipment 

Trunk 
(see note 
703) 

Flue 

Minimum 

flow, 

scfm 

Flow resistance/ 
pressure drop at 
minimum flow (see 
note 701A.l.d), 
in. H 2 0 

Data cabinets 

A 

301B 

225 

0.54 



301C 

260 

— 



305 B 

80 

.50 



305C 

80 

.50 



306B 

290 

.56 



306C 

50 

.50 

Data console 

A 

308B 

100 

.50 



308C 

50 

.50 



309 

0* 

— 



31 OB 

135 

.50 



310C 

50 

.50 

Control console 

E 

405-2A 

100 

1.0 



405-2 B 

100 




405-6A 

50 




405-6B 

50 


Power buffer and 

B 

Oil 

440 

2.0 

conversion 


012 

440 




013-1 

150 




013-2 

150 




015 

440 


Control computer 

D 

440BC 

200 

1.0 

group 


440-441 D 

300 




444BC 

300 




444-445 D 

250 




446BC 

See note 




447BC 

705 



E 

471 

200 


Control group 

E 

450BC 

200 




450-45 ID 

200 




451BC 

100 



C 

452BC 

200 




452-453D 

200 




458BC 

200 




458-459D 

200 




459BC 

150* 



E 

472 

150* 


Power di stribution 

F 

002BC 

150 




003BC 

150 




004BC 

150* 




004D 

150* 


Load 

F 

271BC 

275 

1.0 



27 ID 

0* 

0 



005BC 

100* 

1.0 



005D 

0* 

0 


*Flow reserve capability. 


41 




TABLE D.3. — WATER FLOW RATE INTERFACE PARAMETERS 


[Water inlet temperature: 54 °F max and 48 °F min; temperature alarm set at 56 °F ±1 deg F (increasing) and 47 °F ± 1 deg F (decreasing); see Remarks. 
Working pressure: 85 psig max and 57 psig min. Test pressure, 125 psig max with binnacles to be isolated at vehicle hydrostatic test. Pressure drop: nominal 
differential pressure range, 13 to 23 psid ref. Water quality: dual filters required; filters to 10 pm with 98% efficiency by weight, 20 pm absolute.] 


Function 

Minimum cooling 
capability 

Water flow rate 

Remarks 

Electrostatically supported 
gyro navigator (ESGN) and 
gravity sensor system (GSS) 
binnacle cooling 

2.25-kW gain 

^.O-gal/min nominal total flow for two 
ESGN binnacles and one GSS binnacle. 
The supply shall maintain constant flow 
of 2.0 gal/min ±10% to each binnacle. 

b A remote, low-flow alarm shall be pro- 
vided for the ESGN binnacles and the 
GSS binnacle. 

Reliability of water supply shall support a navigation 
subsystem availability of 0.97. This service requirement 
shall be continuously available during patrol and refit. 
The water temperature shall not vary by more than 
6 deg F when changing at the rate of 0.25 deg F/sec 
maximum. This change shall not occur more than once 
per 30-min period. 

Reserve capability for future 
navigation development 

3.25-kW gain 

2.6-gal/min minimum 


ESGN binnacle cooling 

1.5-kW gain 

a 4.0-gal/min nominal total flow for two 
ESGN binnacles. The supply shall main- 
tain a constant flow of 2.0 gal/min ±10% 
to each binnacle. 




b A remote, low-flow alarm shall be pro- 
vided for the ESGN binnacles. 


Reserve capability for future 
navigation development 

4.0-kW gain 

4.5-gal/min minimum 



a The system shall provide test connections at the inlet and outlet of each binnacle to permit periodic measurement of differential pressure. 
b Local flow indication shall be provided for each binnacle 
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Appendix E 


Compatibility Analysis 


E.l Definition 

Compatibility analysis of the interface definitions contained in 
an ICD is a major tool of interface control. It serves a twofold 
purpose: 

1 . Demonstrates completeness of interface definitioa If any 
interface data are missing or presented in a manner that cannot be 
integrated by using the ICD alone as a data source, the ICD is 
considered deficient. 

2. Provides a record (traceability) that the interface has been 
examined and found to have the right form and fit. This record 
can then be used in evaluating the acceptability of subsequent 
change proposals. 

E.2 Kinds of Data 

The following compilation identifies the kinds of data that 
must be obtained for a compatibility analysis and outlines the 
general steps that should be followed for three categories of 
interface: electrical/functional, mechanical/physical, software, 
and supplied services: 

I. Interface category — electrical/functional 
A. Data required to perform analyses 

1. The following parameters are required, considering 
the specific function or signal involved: 

a. Cabling and connectors 

b. Power requirements 

c. Electromagnetic interference, electromagnetic 
compatability, electromagnetic radiation, and 
grounding requirements 

d. Functional flow and timing requirements 

e. Signal definition 

f. Digital data definition to the bit level 

g. Protocol levels 

h. Seven-layer International Standards Organization 
open systems instruction stack definition or its 
equivalent 

i. Error recovery procedures 

j. Startup and shutdown sequences 

k. Adequacy of standards used or referenced 

2. Unique requirements for an interface or a piece of 
equipment different from overall system require- 
ments (i.e., the hierarchy of specifications required) 

3. Adequate definition of all signals crossing the inter- 
face. “Adequate” is difficult to define precisely but 


depends on the signal type (e.g., analog or digital) 
and the intended use. In general, the interface must 
show the characteristics of the isolating device (ele- 
ment) on each side of the interface and define the 
signal characteristics in engineering terms suitable 
for the particular type of signal. 

4. Timing and other functional interdependencies 

5. System handling of error conditions 

6. Full definition of any standards used. Most digital 
transmission standards have various options that 
must be selected; few, if any, standards define the 
data that are passed. 

B. Steps to be followed 

1 . Verify interoperability of connectors. 

2. Size cables to loads. 

3. Determine cable compatibility with signal and envi- 
ronmental conditions. 

4. Define data in one document only. 

5. Determine adequency of circuit protection devices 
and completeness of signal definition. 

II. Interface category — mechanical/physical 
A. Type of interface — form and fit 

1. Data required to perform analysis 

a. A datum (reference) that is common to both sides 
of the interface (e.g M a mounting hole in one part 
that will mate with a hole or fastener in the other 
mating parts or a common mating surface of the 
two mating parts) 

b. Dimensions and tolerances for all features of each 
part provided in a manner that gives the optimum 
interface fit and still provides the required design 
functions. Optimum interface means dimension- 
ing so that the tolerance accumulation is kept to a 
minimum. 

2. Steps to be followed 

a. Start with the common datum and add and subtract 
dimensions (adding the tolerance accumulations 
for each dimension) for each feature of the part 
interface. 

b. Determine the dimensional location of the 
interface-unique features by adding and subtract- 
ing the tolerance accumulations from resulting 
dimensions to achieve the worst-case maximum 
and minimum feature definitions. 

c. Perform the same analysis for the mating features 
of the interfacing part. 

d. Compare and question the compatibility of the 
worse-case features of the two mating parts (Will 
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the maximum condition of one part fit within the 
minimum condition of the mating part?) 

B. Type of interface — structural load 

1 . Data required to perform analysis 

a. A description of the loading conditions (static or 
dynamic) and the duration of those conditions 

b. Characteristics of the equipment involved: weight 
or mass; mass distribution; elastic properties; and 
sensitivity of elastic properties to temperature, 
moisture, atmospheric gas content, pressure, etc. 

2. Steps to be followed. This analysis involves placing 
the interfacing items in a position that produces the 
maximum loads while the items are interfacing. A 
space experiment is primarily designed for flight 
loads, yet it must withstand the loads developed 
during the launch and deployment cycles and per- 
haps unique loads during launch processing. The 
complexity of the compatibility analysis will vary 
depending on the types of interfacing items and 
environments. 

a. Attachment loads are the simplest, being a state- 
ment of the loads applied by the attaching feature 
(bolt) and the load capability of the component 
being retained (flange). 

b. Hoisting and handling loads require the calcula- 
tion of bending moments or shear for various 
loading scenarios. Dynamic and environmental 
loads must also be considered. (How quickly i s the 
load applied? What are the wind loading factors?) 

c. A more complex situation will be the loads devel- 
oped during a dynamic interaction of interfacing 
items where different material characteristics must 
be considered along with the reaction characteris- 
tics of the materials (e.g., a flexible beam of 
varying moments of inertia supported by an elas- 
tomeric medium where the entire system is 
subjected to a high-velocity impulse of a few 
microseconds duration). Such a condition could 
produce loads that exceed those for which one of 
the interfacing items is designed. Another inter- 
facing item may have to be redesigned so as not to 
jeopardize the mission of the primary item (i.e., 
increasing the strength of the item bei ng supported 
could increase the weight). 

III. Interface category — software 

A. Type of interface— software. The ICD is required to 
specify the functional interface between the computer 
program and any equipment hardware with which it 
must operate. Often, the supplier documentation for 
standard computer peripherals and terminals is ad- 
equate for this purpose. Conversely, it has been found 
that performance specifications governing the design 
of new equipment are not satisfactory for use in a 


functional ICD. The purpose of an ICD is to communi- 
cate equipment interface requirements to programmers 
in terms that the programmers readily and accurately 
understand and to require equipment designers to con- 
sider the effect of their designs on computer programs. 

B. Type of interface — hardware/software integration. The 
ICD provides an exact definition of every interface, by 
medium and by function, including input/output 
control codes, data format, polarity, range, units, bit 
weighting , frequency, minimum and maximum timing 
constraints, legal/illegal values, accuracy, resolution, 
and significance. Existing documentation may be ref- 
erenced to further explain the effect of input/output 
operations on external equipment. Testing required to 
validate the interface designs is also specified. 

IV. Interface category — supplied services 

A. Type of interface — fluid service 

1. Data required to perform analysis 

a. Type of fluid required by the equipment and 
type of fluid the service supplier will provide. 
This may be in the form of a Federal or military 
specification or standard for both sides or for 
one side of the interface. 

b. Location of the equipment/service interface 
(hose connection, pipe fitting, etc.) 

c. Equipment requirements at the interface loca- 
tion in regard to characteristics (pressure, tem- 
perature, flow rate, duty cycle, etc.) 

d. Capability of the service supplier at the interface 
location 

e. Manner in which the equipment can affect the 
capability of the service supplier (e.g., having a 
large backpressure that the supplier fluid must 
push against or a combination of series and 
parallel paths that the supplier fluid must pass 
through) 

2. Steps to be performed. Examine the supplier and 

equipment requirements to determine 

a. If the supplier capability meets or exceeds the 
equipment requirements. This may require con- 
verting a Federaiymilitary specification or stan- 
dard requirement into what is specified for the 
equipment. 

b. If the supplier capability meets the require- 
ments, considering the effects resulting from the 
fluid passing through the mating equipment 

B. Type of interface — environmental 
1 . Data required to perform analysis 

a. Conditions required for equipment to function 
properly. Storage, standby, and operating 
scenarios need to be established and defined. 

b. Supplier’s capability to provide the environ- 
ment specified in terms of time to reach steady 
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state from transients resulting from uncontrol- 
lable external environments; the limits of the 
steady-state conditions (maximum/minimum); 
and monitoring features 

2. Steps to be performed. Perform analyses (e.g., 
thermal) under extreme and nominal environmen- 
tal conditions to verify that supplier’s equipment 
can maintain the environment required for the 
equipment. The complexity of the analysis may 
vary depending on the types of item involved. 


a. Simple inspection, which considers the environ- 
ment required by an item versus the capability of 
the ambient in which the item resides 

b. Complex analysis, which must consider uncon- 
trolled external environmental inputs, the ther- 
mal properties of intermediate systems that do 
not contribute to the end environment but act as 
conduits or resistors in the model, and the inter- 
action of the item and the system that controls 
the desired environment 
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Appendix F 

Bracket System for Interfaces 


Brackets are used on hardware/engineering drawings to flag 
or identify details controlled by the ICD. Changes cannot be 
made to the drawings or designs without the effects on the 
interface being assessed and coordinated through the ICD 
process. 

The process uses a rating similar to that used in the problem/ 
failure reporting bracket system with the same controls and 
traceability. Once a bracket has been assigned to an interface 
void or problem, specific analyses and actions are required for 
the bracketed item to be removed. The bracketed item remains 
in open status with assignment to the responsible cognizant 
subsystem or design section until (1) the corrective action or 
coordinated information has been developed, (2) a proper risk 
assessment has been performed, (3) ICD change actions have 
been completed, (4) adequate verification of the interface is 
planned, and (5) the proper approval signatures have been 
obtained. 

The following ratings are used to establish a category of 
“bracket” identifiers for interface deficiencies. Any discrep- 
ancy having an A rating greater than 1 or a B rating greater than 
2 will be designated a bracketed discrepancy (see figure F. 1 ). 

I. Interface deficiency rating A (S&MA impact) 

A. Rating Al: Negligible effect on interface or mission 

performance 

1 . No appreciable change in functional capability (form, 
fit, and function are adequate for the mission) 

2. Minor degradation of engineering or science data 

3. Support equipment or test equipment failure but not 
mission-critical element failure 

4. Support-equipment- or test-equipment-induced 
failures 


5. Drawing errors not affecting element construction 

B. Rating A2: Significant degradation to interface or 
mission performance 

1 . Appreciable change in functional capability 

2. Appreciable degradation of engineering or science 
data 

3. Significant operational difficulties or constraints 

4. Decrease in life of interfacing equipment 

5. Significant effect on interface or system safety 

C. Rating A3: Major degradation to interface or mission 
performance or catastrophic effect on interface or 
system safety 

II. Interface deficiency rating B (understanding of risk) 

A. Rating Bl: Effect of interface deficiency is identified 
by analysis or test, and resolution or corrective 
action is assigned and scheduled or implemented 
and verified. There is no possibility of recurrence. 

B. Rating B2: Effect of interface deficiency is not fully 
determined. However, the corrective action proposed, 
scheduled, or implemented is considered effective in 
correcting the deficiency. There is minimal possibility 
of recurrence and little or no residual risk. 

C. Rating B3: Effect of interface deficiency is well 
understood. However, the corrective changes pro- 
posed do not completely satisfy all doubts or concerns 
regarding the correction, and the effectiveness of 
corrective action is questionable. There is some poss- 
ibility of recurrence with residual risk. 

D. Rating B4: Effect of interface deficiency is not well 
understood. Corrections have not been proposed or 
those proposed have uncertain effectiveness. There is 
some possibility of recurrence with residual risk. 
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Interface discrepancy red flag; 

project or task manager approval required 


Rating A 
(S&MA impact) 

Numerical rating 

Rating B 

(understanding of risk) 

Negligible 

impact 

1 

1 

Known deficiency with corrective action 
assigned, scheduled, and implemented 

Significant 

degradation 

2 

2 

Deficiency poorly defined but acceptable 
corrective action proposed, scheduled, and 
implemented (low residual risk) 

Major 

degradation 

3 

3 

Known deficiency but effectiveness of 
corrective action is unclear and does not 
satisfy all doubts and concerns (residual risk) 


I- ' • : V ‘ 

! ■ ■ • : ' : 

4 

Impact not defined with confidence; 
corrective action with uncertain 
effectiveness (residual risk) 


Figure F.1 . — Interface deficiency rating system. 
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Appendix G 

ICD Guidelines 


1 . Interface control documents should not require the designer of the 
mating interface to assume anything. ICD’s should be compatible with 
each other and stand alone. 

2. Only the definition that affects the design of the mating interfaces 
need be used. 

3. ICD’s should not specify design solutions. 

4. The ICD custodian should be independent of the design organiza- 
tion. 

5 . The ICD custodian should verify that the data being controlled by 
an ICD are sufficient to allow other organizations to develop the 
interface described by the ICD. 

6. An interface control system should be in place at the beginning of 
system (hardware or software) development. 

7. Each void should have a unique sequential identifier establishing 
due dates, identifying exact data to be supplied, and identifying the data 
supplier. 
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Appendix H 

Glossary 


baseline — The act by which the program manager or a desig- 
nated authority signs an interface control document (ICD) and 
by that signature establishes the genuineness of the ICD as an 
official document defining the interface design requirements. 
The term “baseline” conveys the idea that the ICD is the only 
official definition and that this officiality comes from the 
technical management level. Not only is the initial version of 
the ICD baselined, but each change to an ICD is likewise 
approved. 

comment issue — An issue of an ICD distributed for review and 
comment before a meeting of the affected parties and before 
baselining 

custodian — The contractor or project assigned the responsibil- 
ity of preparing and processing an ICD through authentication 
and subsequently through the change process 

data — Points, lines, planes, cylinders, and other geometric 
shapes assumed to be exact for the purpose of computation and 
from which the location or geometric relationship (form) of 
features of a piece of equipment can be established 

interface responsibility matrix — A matrix of contractors, 
centers, and project organizations that specifies responsibilities 
for each ICD listed for a particular task. Responsibilities are 
designated as review and comment, technical approval, 
baselining, and information. 

electrical/functional interface — An interface that defines the 
interdependence of two or more pieces of equipment when the 
interdependence arises from the transmission of an electrical 
signal from one piece of equipment to another. All electrical 
and functional characteristics, parameters, and tolerances of 
one equipment design that affect another equipment design are 
specified. 

interface — That design feature of one piece of equipment that 
affects a design feature of another piece of equipment. An 
interface can extend beyond the physical boundary between 
two items. (For example, the weight and center of gravity of 
one item can affect the interfacing item; however, the center of 
gravity is rarely located at the physical boundary. An electrical 
interface generally extends to the first isolating element rather 
than terminating at a series of connector pins.) 

interface control — The process of (1) defining interface re- 
quirements to ensure compatibility between interrelated pieces 


of equipment and (2) providing an authoritative means of 
controlling the interface design. 

interface control document (ICD) — A drawing or other docu- 
mentation that depicts physical and functional interfaces of 
related or cofunctioning items. (The drawing format is the most 
common means of controlling the interface.) 

interface control working group — A group convened to 
control and expedite interface activity between the Govern- 
ment, contractors, and other organizations, including resolu- 
tion of interface problems and documentation of interface 
agreements 

interface definition — The specification of the features, char- 
acteristics, and properties of a particular area of an equipment 
design that affect the design of another piece of equipment 

interoperability — The ability of two devices to exchange 
information effectively across an interface 

mechanical/physical interface — An interface that defines the 
mechanical features, characteristics, dimensions, and toler- 
ances of one equipment design that affect the design of another 
subsystem. Where a static or dynamic force exists, force 
transmission requirements and the features of the equipment 
that influence or control this force transmission are also de- 
fined. Mechanical interfaces include those material properties 
of the equipment that can affect the functioning of mating 
equipment or the system (e.g., thermal and galvanic 
characteristics). 

software interface — The functional interface between the 
computer program and any equipment hardware with which it 
must operate. Tasking required to validate the interface designs 
is also specified. 

supplied-services interface — Those support requirements that 
equipment needs to function and that are provided by an 
external separate source. This category of interface can be 
further subdivided into environmental, electrical power, and 
communication requirements. 

technical approval — The act of certifying that the technical 
content in an interface document or change issue is acceptable 
and that the signing organization is committed to implementing 
the portion of the interface design under the signer’ s cognizance. 
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Training Answers 

Chapter Answers 

1 1 (A); 2(D); 3(C); 4a(C), 4b(A), 4c(B) 

2 1(D); 2(C); 3a(B), 3b(C); 4a(C), 4b(C), 4c(C); 
5a(A), 5b(A), 5c(A); 6a(C), 6b(A), 6c(A); 
7a(B), 7b(B), 7cA(i), 7cB(ii), 7cC(i); 8a(B), 
8b(A); 9a(A), 9b(A), 9c(B) 

3 1 a(A), lb(B), lc(B); 2a(B), 2b(A), 2c(B); 
3a(A), 3b(B), 3c(A); 4a(B), 4b(A), 4c(B); 
5a(A), 5b(B); 6a(A), 6b(B), 6c(B), 6d(B); 
7a(B), 7b(A), 7c(A), 7d(A), 7e(A) 


51 


REPORT DOCUMENTATION PAGE 


Form Approved 
OMB No. 0704-0188 


Public reporting burden for this collection of information is est.mated to average 1 hour per response, including the time for reviewing 

oatherina and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate o _any other ^aspect ofthts 
collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, 20503 

Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DU ZQ50J 


1 . AGENCY USE ONLY (Leave blank) 


4. TITLE AND SUBTITLE 


2. REPORT DATE 


January 1997 


3. REPORT TYPE AND DATES COVERED 

Reference Publication 


5. FUNDING NUMBERS 


Training Manual for Elements of Interface Definition and Control 


6. AUTHOR(S) 

Vincent R. Lalli, Robert E. Kastner, and Henry N. Hartt 


WU -323^2-02 


7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 

National Aeronautics and Space Administration 
Lewis Research Center 
Cleveland, Ohio 44135-3191 


8. PERFORMING ORGANIZATION 
REPORT NUMBER 


E-9790 


9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESSES) 

National Aeronautics and Space Administration 
Washington, DC 20546-0001 


10. SPONSORING/MONITORING 
AGENCY REPORT NUMBER 


NASA RP-1370 


11. SUPPLEMENTARY NOTES 

This manual was edited by Vincent R. Lalli, NASA Lewis Research Center; Robert E. Kastner, Vitro Corporation, 
Rockville, Maryland; and Henry N. Hartt, Vitro Corporation, Washington, DC. Responsible person, Vincent R. Lalli, 

(216) 433-2354. 

12a. DISTRIBUTION/AVAILABILfTY STATEMENT ~ _ 12b - DISTRIBUTION CODE 

Unclassified - Unlimited 
Subject Category 15 

This publication is available from the NASA Center for Aerospace Information, (301) 621-0390. 

Multiple copies are for sale by the National Technical Information Service, Springfield, VA 22161, 

(703) 487-4822. 

13. ABSTRACT (Maximum 200 words) 

The primary thrust of this manual is to ensure that the format and information needed to control interfaces between 
equipment are clear and understandable. The emphasis is on controlling the engineering design of the interface and not on 
the functional performance requirements of the system or the internal workings of the interfacing equipment. Interface 
control should take place, with rare exception, at the interfacing elements and no further. There are two essential sections 
of the manual. Chapter 2, Principles of Interface Control, discusses how interfaces are defined. It describes different types 
of interfaces to be considered and recommends a format for the documentation necessary for adequate interface control. 
Chapter 3, The Process: Through the Design Phases, provides tailored guidance for interface definition and control. This 
manual can be used to improve planned or existing interface control processes during system design and development. It 
can also be used to refresh and update the corporate knowledge base. The information presented herein will reduce the 
amount of paper and data required in interface definition and control processes by as much as 50 percent and will shorten 
the time required to prepare an interface control document. It also highlights the essential technical parameters that ensure 
that flight subsystems will indeed fit together and function as intended after assembly and checkout. 


14. SUBJECT TERMS 

Systems engineering; Configuration control; Documentation; 
Change notices; Interface management 


17. SECURITY CLASSIFICATION 
OF REPORT 

Unclassified 

NSN 7540-01 -280-5500 


IB. SECURITY CLASSIFICATION 
OF THIS PAGE 

Unclassified 


19. SECURITY CLASSIFICATION 
OF ABSTRACT 

Unclassified 


15. NUMBER OF PAGES 

60 

16. PRICE CODE 

A04 

20. LIMITATION OF ABSTRACT 


Standard Form 298 (Rev. 2-89) 
Proscribed by ANSI Std. Z39-18 
298-102 







National Aeronautics and 
Space Administration 

Lewis Research Center 

21000 Brookpark Rd. 
Cleveland, OH 44135-3191 



